Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spawn liquids when dripping #122

Draft
wants to merge 18 commits into
base: V1.3
Choose a base branch
from

Conversation

FeatherAntennae
Copy link
Contributor

A small tweak I made for myself, but I thought I'd share here.
Made the dripping mechanic spawn liquid semen if spawning liquid is enabled in the configs.

Feel free to close without merging if the feature isn't wanted.
Otherwise, let me know if I should tweak anything before it's merged.

ErinaSugino and others added 17 commits May 25, 2024 19:57
Fixed a typo in the position file for reverse_cowgirl, making no dialog load, ever.
Modified the zLevel of actor2's tail to be under actor1's groin
When using `uninitActors()` to flush a sexnode, the positions were never reset, as this bypasses the normal "remove actor" pipeline. This results in any attempt to add another actor afterwards, when it was flushed in non-idle state, to break. This is because the position filtering on the first added actor is done in null state, not actually switching to idle, never updating the current position pointer, which then points to an nil entry in the position list. This is now fixed.
Also added more failsafety to the system and reduced old commented out code, as well as reduced log spam on unnecessary duplicate "uninitActors" calls.
Fixed that the front arm layer of the tentacleplant v2 needs to be above actor 2's by new layer numbers.
Making the change from 22906f4 affect only the butterfly position.
Added ability to remove infertility on player entity for 2000 Sexbux to customizer UI. This allows for infertility to be added throughout gameplay without being a permanent punishment. It also makes Neki players less confused, as they can see their infertility state now.
Made infertility cancel and disable ovulation.
Caches which entities IDs have started and stopped sex music, and forcibly sends the stop music command on uninit to all still registered listeners.
Should fix the issue, where destroyed (smashed) or timeouted nodes (where the player unlounges, losing the status effect, triggering the stop message chain BECAUSE the node doesn't exist anymore) kept the music playing forever, until you lounge and unlounge in another node.

Fixes ErinaSugino#113
Update sexbound_tentacleplant_v2.object
Literally just forgot to *actually* define the callback function. This shit's been giving me way too many sleepless nights.
Fixed non-refactored references on pregnancy stage check.
Fixed missing entity message encoding for generated baby colors from actor to entity. Thanks again, Chucklefish.
Updated version number to 1.2 Revision 1.
Added changelog for revision 1.
Made all arousal/heat effects configurable per species and by user preference.
Species file parameter "sxbHeatDuration" determines how long the heat effect should last for the given species.
"effectConfig" on the corresponding statuseffect file has settings per species (plus default) on what the effects do.
"arousal" section in main config file allows users to tweak effects globally.
Made arousal/heat effect scripts efficiently modularized.
Copy link
Owner

@ErinaSugino ErinaSugino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand this comes from a personal DIY change, however some changes are needed for proper implementation.

First and foremost, hardcoding the liquid ID is never a good idea. It should correspond to the right liquid, as Sexbound supports defining different liquid per species. Lewdbound, for example, utilizes this. So it would need to check the config for the right liquid.

Between that and my suggestion to maybe utilize a projectile to spawn the liquid - as is done normally - you could just call self:spawnProjectile() to do this for you.

However, this highlights another logical problem with this; the liquid supposed to drip is not the one of this entity, but of the entity that climaxed in the past. In order to properly account for this, a more data-rich way of storing accumulated liquid would need to be implemented, which keeps track of the types of climax liquid the climaxing actor inserts. Aswell as, possibly, the ability to spawn a mixture of multiple liquids on dripping. This, however, I would consider highly optional.

@FeatherAntennae
Copy link
Contributor Author

Since I'm not too familiar with the project as a whole, I prefer asking first. Should the storage for liquid type and quantity live in the climax plugin directly, or would it be better somewhere else? Is there a developer chat, or anywhere I could poke if I have some questions?

I don't have much experience modding Starbound in particular, but I'd love to contribute more to this project, so might as well do it right! Sounds like a good place to start to understand how things interact, too.

@ErinaSugino
Copy link
Owner

A dedicated developer chat not exactly, however I do have my own corner with constant lunatic dev talk on the adult modding Discord server https://discord.gg/AnZ7QA4BfR

That's definitely faster (and less mail inbox filling) to communicate.

@FeatherAntennae
Copy link
Contributor Author

FeatherAntennae commented Jun 30, 2024

I added a way to track the types of climax liquid inflating an actor and spawn the corresponding liquids on dripping.

It's my first time doing anything like that in lua, so I'm not sure the inflation.lua file follows good practices or not.

@ErinaSugino Let me know if you think anything should be done in a different way.

@@ -23,7 +24,7 @@ function Sexbound.Actor.Climax:new(parent, config)
_scenarios = {},
_soundEffects = {},
_timer = {},
_inflation = 0,
_inflation = {},
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why exactly are you instantiating variables as a table, when they later should be filled with a "class instance"? Assuming there ever be a case where the variable isn't properly filled later yet you still work with it, latest when you try to call a sub-function on it will you get a nil error.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The short answer is: "I have no idea what I'm doing." ^^''

The lua doc told me there are no classes, only tables and weirder tables. So I thought declaring the internal variables as empty tables to be replaced by the instance later was the right thing to do.

This is exactly why this code needs review, sorry for the extra work. ;v;

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well yes, Lua does not have classes or anything fancy at all. It has metatables, which is a weirder way to use old JavaScript prototypes.

However, strictly speaking defining a variable as an empty table and then replacing it with a different "funky" table just allocates unnecessary resources. And so, since it does not offer any failsave protection I'd say it's not necessary. Sure, reading values doesn't crash the script, as the table exists and any value read from the table is now "nil" instead of a "Trying to index nil value" error - but since it's supposed to be a "class instance" later down the line and 90% of all calls on it will be function calls, it will error regardless. Best to not initialize it at all and, if failsafety is needed, just do a quick if self._inflation then ... end

"Quantity: ["..inflationLoad.quantity.."]")

-- Add to the last load if it has the same liquid id
if self._loadCount > 0 and self._loads[self._loadCount].liquid == inflationLoad.liquid then
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a split point here.

Option A: In case we continue to just track the different liquid types there is no need to make a cocktail stack and only ever check the last layer for the same liquid - just iterate over all different stored liquids and add to the pile that fits, if any does.

Option B: Since you already do keep track of strongly seperated loads, might as well future-proof it by also tracking which entityId the liquid belongs to. In that case the "liquid" equality check is redundant, as the same entity should only ever produce the same liquid, and that information can later be used when the system gets expanded to track "stored" liquids even outside of the sexnode, on the actual entity. Could be used for more realistic means of post-sex impregnation and other effects, like dripping.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Appendix:
Yes, the first approach would naturally require to change up the "remove" logic - probably just a simple "determine percentage that is to be removed, then remove that from all stacks. Anything <0.01 gets removed entirely."

@FeatherAntennae FeatherAntennae changed the title Spawn semen when dripping Spawn liquids when dripping Jun 30, 2024
@ErinaSugino ErinaSugino marked this pull request as draft July 14, 2024 18:14
@ErinaSugino ErinaSugino changed the base branch from main to V1.3 July 14, 2024 18:14
@ErinaSugino
Copy link
Owner

I'll forward this officially to the 1.3 update, as that one will be all about climax mechanics to begin with. We'll keep this as working base but can expand upon it as it will be eventually needed in regards to the future 1.3 changes.

@FeatherAntennae
Copy link
Contributor Author

I'll forward this officially to the 1.3 update, as that one will be all about climax mechanics to begin with. We'll keep this as working base but can expand upon it as it will be eventually needed in regards to the future 1.3 changes.

Sounds good! I'll add whatever is needed. Should have more time to get back on this starting sometimes next week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants